Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support multiple archives with "priority" field #160

Merged
merged 13 commits into from
Oct 18, 2024

Conversation

letFunny
Copy link
Collaborator

@letFunny letFunny commented Oct 3, 2024

This commit adds support for fetching packages from multiple archives. It introduces a new field archives.<archive-name>.priority which takes in a signed integer and specifies the priority of a certain archive. A package is fetched from the archive with highest priority and negative priorities are ignored unless explicitly pinned in a package.

The concept of default archive in chisel.yaml is now deprecated. However, the field can still be present and it will be parsed but IGNORED.

DEPRECATED: "archives..default" field in chisel.yaml.

  • Have you signed the CLA?

This commit adds support for fetching packages from multiple archives.
It introduces a new field `archives.<archive-name>.priority` which
takes in a signed integer and specifies the priority of a certain
archive. A package is fetched from the archive with highest priority.

It also deprecates the concept of default archive in chisel.yaml.
However, the field can still be present and it will be parsed but
IGNORED.

DEPRECATED: "archives.<archive>.default" field in chisel.yaml.
---------

Co-authored-by: Alberto Carretero <[email protected]>
@cjdcordeiro cjdcordeiro added the Priority Look at me first label Oct 7, 2024
Copy link
Contributor

@niemeyer niemeyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good! Mostly trivial comments.

internal/setup/setup.go Show resolved Hide resolved
internal/setup/setup.go Show resolved Hide resolved
internal/setup/setup.go Show resolved Hide resolved
internal/slicer/slicer.go Outdated Show resolved Hide resolved
internal/slicer/slicer.go Outdated Show resolved Hide resolved
internal/slicer/slicer.go Outdated Show resolved Hide resolved
@letFunny letFunny closed this Oct 17, 2024
@letFunny letFunny deleted the multiple-archive-support branch October 17, 2024 08:37
@letFunny letFunny restored the multiple-archive-support branch October 17, 2024 08:39
@letFunny letFunny reopened this Oct 17, 2024
Copy link
Contributor

@niemeyer niemeyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's looking good. Just one detail about zero priorities being slightly loose.

return nil, fmt.Errorf("%s: archive %q has invalid priority value of %d", fileName, archiveName, details.Priority)
}
if details.Priority != 0 {
hasPriority = true
Copy link
Contributor

@niemeyer niemeyer Oct 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The handling of priority zero seems a bit loose at the moment. We consider it not being zero here as "it has priority", but then right below we actually define the default (!) priority as zero. Also, we error if two priorities are the same, which forces people to enter a priority value for all but one of them, which will be automatically set to zero due to how yaml unmarshaling takes place on the int type.

It looks like we might fix all of these issues at once by forcing the priority, if present, to be either positive or negative, and considering zero to be unset per the test above. On unmarshalling, we can clarify the situation further by having the Priority field on the yaml type being a pointer, so we can differentiate between unset and zero, and then failing on inconsistency (any priority is set but some not, or no default and no priority).

Copy link
Collaborator Author

@letFunny letFunny Oct 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 418ea0d, I have changed the priority to be a pointer so we can distinguish when it is 0 and when it is unset. Also, we now return an error in the case there is an inconsistent use of priorities. The only bit I am not sure about is the error message when there are no priorities set across several archives (I have included a test in the commit to show that use-case).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the error we want in those cases is to point out just one of them as a hint. Something like:

error: archive %q is missing the priority setting

We can raise this when there is no defaultArchive, and we have a priorityArchive (which needs support, equivalent to noPriorityArchive).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. We know check if there is more than one archive and there is no default and there are no priorities.

Copy link
Contributor

@niemeyer niemeyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up:

}
} else {
if hasPriority {
return nil, fmt.Errorf("%s: archive %q missing priority", fileName, archiveName)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't need the criss-cross check and double error message, if we move this to a single check at the end, where we're already verifying priorities anyway at line 601:

if hasPriority {
    if archiveNoPriority {
        ... error ...
    }
} else if defaultArchive {
    ...
}

We might also turn the branch here in line 586 into:

} else if archiveNoPriority == "" {
      archiveNoPriority = archiveName
}

So we only pick up the first one.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with the suggestions. The only thing I have changed is to make the branch in line 586 deterministic by ordering the archive names.

// not being used, we will revert back to the default archive behaviour.
hasPriority := false
var defaultArchive string
var archiveNoPriority string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

noPriorityArchive would be friends with defaultArchive :)

internal/setup/setup.go Outdated Show resolved Hide resolved
internal/setup/setup.go Outdated Show resolved Hide resolved
return nil, fmt.Errorf("%s: archive %q has invalid priority value of %d", fileName, archiveName, details.Priority)
}
if details.Priority != 0 {
hasPriority = true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the error we want in those cases is to point out just one of them as a hint. Something like:

error: archive %q is missing the priority setting

We can raise this when there is no defaultArchive, and we have a priorityArchive (which needs support, equivalent to noPriorityArchive).

@niemeyer niemeyer merged commit 7eb8428 into canonical:main Oct 18, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority Look at me first
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants